程式碼行數（Lines of Code, LoC）過去常被用來觀察工程活動量。
當開發工作主要由開發者手動完成時，程式碼增加多半伴隨需求分析、設計、撰寫、除錯與調整等工作。這項指標精確度有限，只能在一定程度上反映團隊投入的時間與工作量。
行數增加只代表系統多了一些程式文字，無法直接說明這些程式是否解決了正確的問題。
某項功能新增五百行程式，最後可能只處理一個很小的使用情境。另一項修改只刪除二十行重複邏輯，卻能降低理解成本，讓系統較容易維護與修改。
從使用者角度來看，價值來自問題獲得解決、操作流程更順暢，以及錯誤數量減少。這些成果很難直接從行數判斷。行數增加不代表團隊已經正確理解需求，也無法證明系統品質、交付進度與使用者價值有所提升。
AI 讓這項指標的限制變得更明顯。生成工具很擅長補出看似完整的程式結構，包括類別、介面、錯誤處理、測試草稿與文件註解。這些內容放進拉取請求（Pull Request, PR）後看起來十分豐富，實際價值仍需回到需求情境中檢查。
需求理解一旦出現偏差，AI 產出的內容越完整，錯誤方向就會越快進入程式、測試與文件。
評估開發效能時，應檢查這些程式是否協助使用者取得預期結果、是否降低後續維護成本，以及是否讓系統較容易修改。
行數增加可能代表新能力已經加入，也可能代表系統複雜度提高。這兩種情況在程式碼行數指標中都會呈現為數字上升，因此應搭配需求驗證、缺陷率、返工比例與程式碼審查結果共同解讀。
指標一旦被用來評估個人或團隊表現，就會開始改變工作行為。
當行數、提交次數與完成任務數受到高度重視，開發者可能會為了取得高分，產生更多可以被計算的內容。AI 降低了程式生成成本，也讓這類行為較容易出現。
原先能以簡單邏輯完成的需求，可能被展開成多個類別與方法。可以共用的規則，可能被複製到不同模組。需要先釐清的例外情境，也可能直接由 AI 補成一套看似完整的處理流程。這些內容會增加行數與提交紀錄，也會提高系統的理解與維護成本。
這類產出能讓數字看起來更充足，相關成本則會進入後續流程。開發者要閱讀生成內容，審查者要檢查設計意圖與風險，測試人員要確認測試是否涵蓋實際使用情境，維運人員也要承接新增的執行路徑與錯誤狀態。產出規模擴大後，理解、驗證與維護工作也會隨之增加。
好的度量方式會把討論帶向交付結果。管理者觀察開發效能時，可以檢查工作是否順利流動、回饋是否及早出現、缺陷數量是否降低，以及返工是否減少。
這些訊號才能反映團隊是否把時間投入有效工作，也能降低指標引導無效擴張的風險。
數字通膨指的是指標數字上升，實際價值卻沒有同步增加。AI 讓程式碼行數較容易出現這種現象。過去開發者一天寫出一百行程式，需要經過需求理解、設計取捨、撰寫與測試。現在只要輸入一段提示詞，就能產生數百行程式碼。
AI 生成的程式碼也容易出現冗餘。生成工具為了補齊答案，可能加入過多保護邏輯、重複函式、額外抽象層與不必要的設定。這些內容會推高程式碼行數，也會增加閱讀與理解成本。
團隊若沒有在生成後整理程式，短期內可以快速完成初稿，後續修改時卻需要花費更多時間確認每段程式的用途、相依關係與影響範圍。
程式碼行數在 AI 時代適合用來提供診斷線索。小型需求突然新增大量程式時，團隊可以檢查設計是否過度複雜。一次修改刪除大量程式時，可以觀察系統結構與維護成本是否改善。拉取請求規模因 AI 而擴大時，也要檢查程式碼審查的負荷與等待時間是否增加。
把程式碼行數放進價值流、需求範圍與變更風險中解讀，仍能提供有用線索。單獨使用程式碼行數評估工程效能，則容易把快速生成的程式數量誤認為實際交付成果。
週期時間（Cycle Time）是用來觀察一項工作從開始到完成所需的時間。在 AI 時代裡，這個指標需要被重新解讀。AI 可以縮短部分開發活動，例如產生程式碼、建立測試草稿與整理文件初稿，整體交付時間仍會受到其他環節影響。
若團隊只計算「開始寫程式到程式撰寫完成」的時間，數字可能顯示開發效能大幅提升。這段時間只涵蓋價值流中的部分活動，無法反映需求確認、工作拆解、程式碼審查、測試、部署與返工所耗費的時間。
局部開發速度提高，只能縮短價值流中的一段時間，整體交付速度仍取決於後續流程能否順利銜接。
從價值流角度觀察週期時間，應追蹤每個工作項目從開始開發到交付成果的路徑。某項功能從開發到正式上線共花二十天，寫程式只用了兩天，其餘十八天可能分散在等待確認、等待審查、等待測試與等待部署。
這項數據能指出價值停留的位置。改善工作除了縮短程式碼生成時間，也需要處理需求確認、審查排隊、測試準備與部署限制，讓已完成的工作可以繼續向上線階段移動。
週期時間如果只看總天數，團隊只能知道一項工作花了多久，無法看出時間實際消耗在哪些環節。
團隊應該把實際處理時間與等待時間分開觀察。實際處理時間包含需求討論、設計、開發、測試與修正。等待時間則包含排隊、等待確認、等待審查、等待環境與等待部署決策。
AI 對實際處理時間的影響較為直接。開發者可以使用 AI 產生程式草稿、整理測試案例與查找錯誤原因，縮短部分任務的處理時間。
等待時間多半來自團隊協作與組織流程，例如需求缺少明確負責人、程式碼審查排隊過久、測試人員同時承接過多工作，或部署權限集中在少數成員手上。程式碼生成速度提高後，這些等待仍會留在流程中。
等待時間被獨立記錄後，瓶頸才會容易辨識。某類需求平均開發兩天，等待程式碼審查卻需要四天，表示審查流程已經成為主要阻礙。另一類需求只需一天完成開發，等待產品確認卻花了一週，表示需求釐清與決策節奏需要調整。
這些資訊能讓討論聚焦在具體環節。團隊可以依照等待發生的位置，調整責任分工、工作量、審查節奏與部署權限，避免把所有交付問題都歸因於開發速度。
週期時間也要搭配返工比例一起觀察。某項工作第一次完成得很快，後續卻因需求理解錯誤、測試案例不完整或架構設計不合適而多次重做，整體交付時間仍會被拉長。
AI 讓初版實作更快出現，也讓錯誤假設更快進入系統，因此返工比例在 AI 時代更值得關注。
返工常來自理解落差。產品角色認為功能需要支援某種業務情境，開發者根據文件理解成另一套流程，AI 又依照模糊描述補上額外假設。等到測試人員測試、使用者試用或上線後回報問題時，團隊才發現前面的理解沒有對齊。這類返工多半會牽動程式碼、測試、文件、資料、權限與部署安排。
觀察返工比例時，可以記錄需求完成後被退回的次數、拉取請求因需求理解問題而重寫的比例、測試階段發現規格落差的數量，以及上線後因需求不符而產生的修正工作量。
這些訊號能判斷週期時間變長的原因，並確認問題是出在技術處理、需求理解或決策節奏中的哪個環節。
當週期時間與返工比例一起解讀，團隊就能把改善工作提前到需求驗證階段。需求可以先用具體範例釐清行為規則，重要流程可以先製作原型（Prototype），AI 生成前也要確認限制條件與驗收標準。
這些做法能讓工作進入開發時更接近正確方向，減少後續反覆修正造成的時間損耗。
DORA 指標（DORA Metrics）主要用來觀察軟體交付的四個核心面向：部署頻率（Deployment Frequency）、變更前置時間（Lead Time for Changes）、變更失敗率（Change Failure Rate），以及服務恢復時間（Time to Restore Service）。
這四個指標分別從「交付速度」與「系統穩定性」兩個角度，衡量團隊是否能夠持續、安全地把變更送到正式環境。
DORA 指標常被用來觀察軟體交付能力。它關注變更能否穩定、快速且安全地進入正式環境，也會檢查交付流程是否具備足夠的回復能力。
放在 AI 輔助開發的情境中，DORA 指標能讓團隊減少對程式碼產出量的依賴，把注意力放回實際交付結果。
AI 可以加快功能初稿、測試草稿與文件草稿的產生速度。這些內容仍需經過整合、驗證、部署與正式環境回饋，才能形成可交付的成果。
若生成速度提高，後續審查、測試與部署能力沒有同步調整，工作可能會堆積在拉取請求、測試環境或發布流程中。
DORA 指標會同時觀察交付速度與系統穩定性。團隊在提高部署頻率、縮短變更交付時間時，也要檢查變更失敗率是否上升、服務中斷後能否快速恢復，以及正式環境是否仍維持在可控範圍內。
這些訊號可以判斷 AI 帶來的速度是否真正進入交付流程，也能看出新增產出是否轉化成穩定上線的能力。
部署頻率（Deployment Frequency）觀察團隊將變更部署到正式環境的頻率。較高的部署頻率多半代表團隊能將工作拆成小批次，也具備一定程度的測試、整合與部署自動化能力。
這項指標關注團隊能否按照安全且穩定的節奏，讓變更進入使用者環境。
AI 讓開發者能在短時間內產生大量變更，因此部署頻率需要搭配批次大小一起觀察。團隊每天產生大量程式碼，卻只能每月部署一次，表示交付能力仍受到整合、測試或發布流程限制。工作可能堆積在分支、拉取請求或測試環境中，直到發布前才一次整合，進一步提高變更風險。
團隊若能維持小批次部署，並掌握每次變更的目的、範圍與驗證方式，AI 帶來的開發速度才有機會加快交付流程。批次縮小後，測試範圍、問題定位與回復處理也會更明確。
部署頻率提高時，每次部署的風險仍要維持可控。穩定的高頻部署需要明確的完成定義（Definition of Done, DoD）、自動化測試、功能旗標、回退機制與監控能力。
AI 生成的內容進入交付流程後，同樣要符合這些條件。缺少驗證與回復能力時，部署次數增加會讓未確認的風險更頻繁地進入正式環境。
變更前置時間（Lead Time for Changes）觀察一項需求從第一次程式碼提交（Code Commit），到成功部署至正式環境所需的時間。
這項指標能看見程式提交後，變更停留在哪些環節。AI 可以縮短程式碼撰寫時間，審查、測試、整合、部署排程與核准流程仍可能拉長變更前置時間。
當 AI 讓拉取請求數量增加，程式碼審查可能形成新的排隊點。生成內容若缺少設計背景與變更意圖，審查者就要花更多時間理解需求、檢查架構與確認風險。測試案例若跟不上變更速度，測試人員也要投入更多時間補齊測試、準備資料與追查問題。
這些處理與等待時間都會反映在變更前置時間中，讓團隊看見交付速度受阻的位置。
解讀變更前置時間時，團隊可以將流程拆成幾個階段，包括程式提交到完成審查、完成審查到進入測試、完成測試到開始部署，以及部署後完成驗證。分段記錄後，改善方向會更具體。
若大部分時間停留在審查，團隊可以縮小變更批次，補上設計脈絡並調整審查規則。若時間集中在測試階段，就要補強自動化測試、測試資料與環境準備。若等待主要發生在部署核准，則要檢查發布權限、決策流程與部署窗口是否過度集中。
變更失敗率（Change Failure Rate）觀察部署後造成正式環境問題的比例，例如服務異常、回退、熱修復或使用者受到影響。
平均恢復時間（Mean Time to Restore, MTTR）則觀察事故發生後，團隊多久才能恢復服務。
這兩項指標能補足速度指標的盲點，用來確認交付速度是否建立在穩定的基礎上。
AI 輔助開發提高產出速度後，變更失敗率要被更仔細地追蹤。生成內容可能通過基本測試，卻在邊界條件、權限規則、資料狀態或跨系統互動中出現問題。
部署頻率提高後，若變更失敗率也同步上升，表示驗證與防護能力沒有跟上產出速度。團隊需要重新檢查 AI 使用邊界、程式碼審查重點與測試策略。
平均恢復時間能反映團隊處理正式環境問題時的掌控能力。事故發生後若花很長時間才定位原因，多半代表日誌、監控、追蹤、回退流程或系統理解仍有缺口。
AI 生成的程式若缺少必要紀錄，或寫法不符合團隊慣例，也會增加排錯難度。恢復時間變長時，團隊需要補強可觀測性、事故處理流程與程式可理解性。
DORA 指標的價值，在於同時觀察交付速度與系統穩定性。部署頻率與變更前置時間能說明交付是否加快，變更失敗率與平均恢復時間則能檢查這項速度是否安全。AI 時代的團隊可以用這組指標檢視整條交付流程，確認新增產出能被正式環境穩定承接。
SPACE 框架（SPACE Framework）是一套用來觀察開發者效能與工作狀態的框架。
SPACE 分別代表滿意度與幸福感（Satisfaction and Well-being）、績效（Performance）、活動量（Activity）、溝通與協作（Communication and Collaboration），以及效率與流動（Efficiency and Flow）。
這套框架提醒團隊，工程效能除了交付結果，也要看見開發者在什麼工作條件與心理狀態下完成任務。
導入 AI 輔助開發後，團隊容易看見程式產出增加、提交速度提高，以及初稿數量變多。這些數字能反映部分開發活動，無法完整說明開發者是否能穩定完成高品質工作，也無法呈現理解、驗證與協作所消耗的心力。
開發者若每天需要審查大量 AI 生成內容、修正模糊需求造成的返工，並頻繁切換工具、提示詞與系統上下文，短期內仍可能維持較高的產出數字。長期下來，審查疲勞、注意力分散與理解負荷會影響工作品質、協作效率與交付穩定性。
SPACE 框架能補足活動量指標的限制，讓團隊將工作感受、協作負擔、心理負荷、交付成果與價值流一起納入觀察。
這些資訊可以讓管理者辨識 AI 帶來的速度是否改善整體工作環境，也能看出新增產出是否伴隨額外的理解與審查成本。
滿意度與幸福感（Satisfaction and Well-being）關注開發者能否在工作中維持合理的掌控感、成就感與安全感。
AI 進入開發流程後，開發者的工作內容也會改變。部分程式撰寫工作由工具加速，審查、判斷、整合與驗證所占的比例隨之提高。這項轉變若缺少明確的責任分工與流程設計，開發者容易感覺自己的工作只剩下替 AI 檢查與收尾。
滿意度下降時，問題不一定會立即反映在交付數字上。功能仍能完成，部署仍能進行，任務也會照常關閉。開發者可能已經開始對大量生成內容感到疲乏，對系統的掌控感降低，也承受更多程式碼審查與維護壓力。時間拉長後，這些感受會影響品質判斷、學習意願與人員留任。
團隊可以透過簡短調查、一對一談話、自省會議（Retrospective）與工作負荷討論，蒐集滿意度相關訊號。調查結果應指向消耗開發者的工作環節，例如審查量過高、需求反覆變更、AI 產出缺少脈絡，以及工具與流程過度分散。
這些訊號可以讓團隊提早調整 AI 使用方式、審查分工與工作流程，避免工程效能建立在開發者長期疲勞與掌控感降低之上。
活動量（Activity）可以包含提交次數、拉取請求數量、程式碼審查次數、文件更新、測試執行與任務狀態變更等資料。
AI 讓這些活動較容易增加，因為開發者能更快產生程式碼、測試、文件與分析結果。這些資料可以提供工作狀態的線索，單獨解讀時仍可能產生誤判。
活動量上升可能代表工作流動改善，也可能代表團隊產生了更多需要理解、審查與修正的內容。拉取請求數量增加時，每次變更若維持小型且目的明確，有助於縮短回饋時間。
每個拉取請求若包含大量 AI 生成內容，審查者就要投入更多時間確認需求、設計與風險，審查流程也可能形成新的排隊點。
文件更新增加時，經過驗證的內容能改善共同理解，協助開發者與 AI 掌握系統背景。未經校對的 AI 生成文件可能留下錯誤資訊，讓後續工作建立在不正確的上下文上。
活動量需要搭配溝通協作品質與效率流動一起觀察。團隊可以檢查需求是否形成共同理解、審查討論是否聚焦，以及跨角色確認是否順暢。
也要留意開發者能否保有完整的專注時間、工作是否頻繁被打斷，以及等待與返工是否減少。活動量增加時，溝通品質與流動效率也能維持穩定，才能說明團隊的工作方式確實有所改善。
AI 時代的開發者需要承擔更多判斷工作。AI 產出的內容看起來完整，開發者仍要確認需求意圖、設計合理性、測試覆蓋、資安風險與維護成本。
這些判斷需要高度專注，也會增加心理負荷。團隊若只關注交付速度，容易忽略開發者每天承受的理解與驗證壓力。
心理負荷過高時，程式碼審查可能開始形式化。審查者只確認格式與測試是否通過，較少深入檢查設計意圖與風險。開發者也可能開始避開高風險區域，因為理解成本已經過高。部分成員則可能成為 AI 產出的主要把關者，長期承接大量審查、排錯與救火工作。
這些狀態都會影響交付品質，只是未必會立即反映在速度指標上。
團隊可以透過 SPACE 框架，將心理負荷納入效能討論。當審查疲勞升高，可以限制單次變更大小，並將格式、型別與基礎規則交由自動化工具檢查。當工具切換造成負擔，可以簡化開發流程與工具入口。當 AI 產出提高理解成本，可以要求提交者說明生成範圍、設計意圖與驗證方式。
這些調整能保留開發者的判斷空間，也能支撐穩定的交付能力。
SPACE 框架補充了 DORA 指標較少涵蓋的人員與協作視角。DORA 用來觀察交付速度與系統穩定性，SPACE 則讓開發者的工作狀態、理解負荷與協作條件被看見。
AI 時代的效能度量需要同時納入交付結果與工作狀態，避免團隊將短期產出增加誤認為長期效能改善。
AI 程式碼採納率（AI Acceptance Rate / Adoption Rate）用來觀察開發者接受 AI 建議程式碼的比例。這個指標能協助團隊了解 AI 工具是否融入日常開發流程，以及開發者對生成內容的信任程度。
較高的採納率表示 AI 建議較容易被開發者使用。團隊可以進一步分析哪些工作情境適合導入 AI，例如重複性高的程式撰寫、測試案例產生、文件整理或常見實作模式。
若採納率長期偏低，則需要分析背後原因，可能與生成品質、上下文資訊不足、使用方式缺少共識，或 AI 建議不符合既有架構規範有關。
採納率適合作為觀察 AI 使用狀況的參考指標，不適合單獨判斷導入成效。開發者接受大量 AI 建議後，仍需要確認程式是否經過驗證，以及是否降低後續修改與維護成本。
良好的 AI 採納情況，應該同時反映在程式品質、交付效率與工程流程改善上，讓 AI 成為提升開發能力的輔助工具。
AI 程式碼存活率（AI Code Retention Rate）用來觀察 AI 產出的程式碼，在經過一段時間後是否仍保留於系統中。
團隊可以設定觀察週期，例如 7 天、30 天或更長時間，確認 AI 生成內容後續是否被修改、刪除或重構。
這個指標能補足單純採納率無法呈現的情況。有些 AI 建議在開發階段看起來有效，進入維護階段後，可能因設計不符合需求、結構難以維護或存在重複邏輯而被移除。
當存活率偏低時，團隊需要檢查 AI 使用方式、需求上下文品質與驗證流程，找出影響生成品質的因素。
程式碼存活率也能協助團隊辨識產出膨脹的情況。若 AI 產生大量程式碼，卻有較高比例在短期內被修改或刪除，代表增加的程式碼量沒有轉化為可長期維護的成果。
透過這個指標，團隊可以更準確評估 AI 是否降低開發成本，或只是將成本移轉到後續整理與維護階段。
提示詞與對話輪次（Prompts / Interaction Rounds per PR）觀察一次拉取請求的背後，開發者與 AI 互動了多少次。
這個指標可以反映 AI 使用過程中的溝通成本，也能提供需求品質的線索。
如果一次變更需要大量來回調整，常代表 AI 缺少足夠上下文，或需求描述仍有模糊處。開發者可能需要反覆補充規則、修正方向、解釋架構限制，最後才得到接近需求的結果。
這些互動紀錄可以幫助團隊發現哪些領域需要補充文件、範例或開發規範。
不過，互動輪次較多不一定代表效率較差。探索新方案、複雜設計討論或架構分析，本來就需要多次交流。
團隊應該搭配變更結果一起觀察，例如最終程式品質、程式碼審查時間、返工比例與需求符合程度。當大量對話沒有帶來更好的結果，才代表 AI 使用流程需要改善。
AI 時代的度量，需要同時看見工具使用與實際價值。程式碼採納率可以了解工具是否被使用，程式碼存活率可以檢查產出是否留下長期價值，提示詞與對話輪次則能協助團隊理解需求與 AI 互動成本。
這些指標搭配 DORA、SPACE 與價值流指標一起觀察，才能形成較完整的 AI 開發效能模型。
度量開發效能時，最容易出現的問題，是團隊把指標當成評分表。
當數字被用來比較個人表現，開發者會開始保護自己，主管也容易只關注表面結果。這種度量方式會改變工作行為，讓開發者傾向追求容易被計算的產出，並降低主動揭露阻礙與風險的意願。
時間拉長後，度量資料會逐步失去原有意義。團隊蒐集的數字越來越多，能用來改善工作流程的線索卻越來越少。提交次數、任務完成數或程式碼行數可能持續上升，需求理解、協作品質、技術風險與維護負擔則難以從這些數字中看見。
AI 時代下，這個問題會更加明顯。程式碼、測試、文件與任務拆分都能快速產生，活動量指標容易上升。團隊若沒有先說明度量目的，這些數字會成為新的工作壓力，也可能促使成員產生更多可以被記錄的內容。
改善導向的度量文化，需要讓團隊理解指標的用途。指標應讓等待、返工、交接、審查負荷與品質風險被看見，並用來調整工作方式。
這些資料不適合直接替個人貼上標籤，也不適合脫離工作情境進行排名。
好的度量，應該讓團隊討論工作流動中的問題。當週期時間變長，團隊可以一起檢查需求確認是否耗時過久、程式碼審查是否長時間排隊、測試資料是否準備太慢，以及部署流程是否受到限制。當變更失敗率升高，也能進一步檢視測試策略、審查重點、AI 使用邊界與正式環境監控是否需要調整。
這類討論需要建立在安全感上。指標一旦被用來追究責任，團隊成員就會開始解釋數字、包裝數字，甚至避免讓問題被看見。
改善導向的做法，是先把指標當成共同觀察材料。數字只能提醒團隊某個環節值得進一步了解，後續仍要透過討論、補充資料與情境判斷，找出合適的改善方向。
例如，某個團隊發現拉取請求平均需要等待四天才能進入審查。這項數據無法直接說明審查者是否投入足夠，也不適合立即要求所有人縮短審查時間。
團隊可以進一步檢查拉取請求的規模是否過大、AI 生成內容是否缺少設計說明、審查責任是否集中在少數人身上，以及格式與基礎規則是否能交由自動化工具處理。
度量的價值，來自它能引出具體的改善對話，讓流程中的等待、負荷與風險被看見。
指標一旦變成目標，團隊行為就會開始配合數字調整。若管理者要求提高提交次數，開發者可能把一項小修改拆成多次提交。若要求提高部署頻率，團隊可能增加低價值的小型變更。若要求縮短週期時間，團隊可能優先處理簡單工作，讓複雜需求繼續留在待辦清單中。
這些做法能改善表面數字，卻無法證明交付能力有所提升。
AI 讓這類指標遊戲更容易進行。開發者可以快速產生更多程式碼、測試與文件，也能將工作拆成更多任務。
這些產出只會推高活動量指標，最終仍應該回歸價值流中檢查。使用者是否取得預期價值、缺陷是否減少、返工是否降低，以及系統是否容易理解與修改，才能反映團隊的實際成果。
避免指標失去原意，需要把每項指標連回它原先想回答的問題。部署頻率用來觀察團隊的小批次交付能力，單獨看無法代表交付速度。週期時間用來找出價值流中的等待與阻礙，重點在於找出時間停留的位置。SPACE 中的滿意度與心理負荷用來理解開發者的工作狀態，並不適合轉成新的個人績效分數。
指標應該作為問題入口，幫助團隊提出下一步需要調查的事項。它提供觀察線索，後續仍需要結合工作情境、品質結果與團隊討論，才能形成合理的改善決策。
數據能讓團隊看見哪些地方出現變化，卻很難完整說明背後原因。
週期時間變長，可能來自工作複雜度提高，也可能是等待時間增加。部署頻率下降，可能代表團隊正在處理大型架構調整。滿意度下降，也可能和審查疲勞、需求反覆變更、工具切換或值班壓力有關。只根據數字判斷，容易過早形成結論。
定性觀察可以補足這項缺口。團隊可以透過自省會議、一對一談話、工作日誌、事故回顧、拉取請求討論紀錄與使用者回饋，理解指標背後的工作情境。
例如審查時間拉長時，拉取請求討論紀錄可能顯示需求意圖不夠明確。變更失敗率升高時，事故回顧可能指出測試資料與正式資料存在差異。滿意度下降時，談話內容也可能反映開發者正在承受大量 AI 產出審查壓力。
AI 時代的度量文化，需要同時納入數據與人的經驗。數字用來辨識趨勢，成員的描述則提供工作脈絡。兩者一起進入討論後，改善行動才能貼近實際問題。
團隊可以先從小範圍開始，每次自省會議選擇一到兩項指標，搭配具體案例檢查原因，再形成可追蹤的改善工作。這種度量方式能讓指標成為團隊學習與調整工作流程的工具，減少數據帶來的管理壓力。
iThome鐵人賽
看影片追技術